… by cursor

The Jul 30 entry covers the runner surface and the pagination retirement:
the two new operator reads with their scopes, envelopes and error codes,
the three reads that drop page and page_size, the fleets cursor rename,
the memory envelope change, the retired client flags with their
replacements, and the two additive index migrations. Upgrading leads,
since client and server move together on all four breaks.

The memory page documents the new --starting-after flag alongside the
existing list example, and states that the dashboard panel walks the
cursor to the end so it shows every entry.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Greptile asked for the runner-events entry to name its paging. It was
already in Upgrading, where the template puts breaking changes, but two of
the three list-endpoint references showed starting_after and limit while
that one did not — so the reference line now stands on its own and says to
follow next_cursor.

The drift check then caught the bigger gap, which only became visible once
the product change deployed its OpenAPI: both new operator reads are
published upstream but were absent from docs.json, so the site documented
neither. GET /v1/fleets/runners/{id} and .../{id}/leases join the Fleet
group beside the sibling runner operations.

Runner paths publish as {id}, matching the PATCH and DELETE that already
lived there, so the changelog's five {runner_id} spellings follow the
published spec. The dashboard route keeps {runner_id} — it is a UI path,
not an OpenAPI one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>